I know that this just uses the same pattern as existing code (so just keep on doing this), but it was not a good pattern to begin with. What we are doing here is converting to a string. Such functionality is so fundamental that has optimized it to be LESS THAN 1 line: #[derive(Debug)]. Let's use that, as god intended:

writeln!(output, "Wasm memory persistence: {persistence:?}");

The only "problem" with this is that instead of "keep", you get "Keep". If you really hate the capital "K", you can get rid of it very concisely as follows:

let persistence = format!("{:?}", persistence).to_lowercase();
writeln!(output, "Wasm memory persistence: {persistence}");

Done in b88cd2e — the display string is now derived via format!("{persistence:?}").to_lowercase(), as suggested.

Generated by Claude Code

Ok, but how about mode? That's why I said,

I know that this just uses the same pattern as existing code (so just keep on doing this)

This thread was more of a rant than an actual suggestion.

Understood. For mode specifically, the Debug trick doesn't quite work: the Upgrade variant carries a payload, so {mode:?} would print Upgrade(Some(CanisterUpgradeOptionsInput { .. })) rather than a clean Upgrade — hence the hand-written match stays there.

Generated by Claude Code

Wouldn't it make more sense to follow through, i.e. install the wasm? I mean, ultimately, what we really want to see is that Keep and skip_pre_upgrade were actually, you know, PERFORMED as requested, right??

Done in b88cd2e — the test now installs the module first, then the approved upgrade executes with wasm_memory_persistence = replace + skip_pre_upgrade and wait_for_request asserts it completed, so the options are exercised through the management canister rather than left pending. One caveat: it uses replace instead of keep, because the test canister isn't built with Enhanced Orthogonal Persistence and the IC rejects keep for modules without the EOP metadata section. Truly proving keep preserves memory would need a Motoko EOP fixture wasm, which felt out of scope here.

Generated by Claude Code

out of scope here.

I don't think so. The whole motivation here is so that I can install a canister that was recently written in Motoko (and therefore, uses EOP).

Fair point — done in 595ddfd. New integration test canister_upgrade_with_wasm_memory_persistence_keep: it marks the test module as EOP by appending the icp:private enhanced-orthogonal-persistence custom section (which is exactly how the IC detects EOP support — no Motoko toolchain needed), installs it, and then shows the same upgrade request fails without keep (the IC's safety check refuses to drop an EOP canister's main memory) and executes successfully with keep. That exercises the real motivating scenario end-to-end through the station.

Generated by Claude Code

This looks like sweeping a problem under the rug.

Done in b88cd2e — the catch-all default: arm is gone; 'default' is now an explicit case with a comment explaining it means "let the IC decide" and maps to an absent wasm_memory_persistence option in the request. The select's items are constrained to the three options, so every case is now spelled out.

Generated by Claude Code

Does the IC decide automatically?? If so, then, it seems that this feature is not super necessary.

No — the IC never infers keep. What it does is fail closed: upgrading a canister whose module declares EOP without keep is rejected outright (so no silent memory loss, but also no upgrade). It's dfx that infers client-side from the Wasm metadata and fills the flag in for you. So the option is necessary — without it, EOP canisters simply cannot be upgraded through Orbit at all. The new integration test in 595ddfd demonstrates both halves (rejected without keep, succeeds with it).

Generated by Claude Code